iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 2
0

由於工作上的需求,一開始就先切入AssetGraph的探索。

遊戲的開中少不了資料的引用,一直以來,資料多以文字格式或是二進位內容的方式保存下來並於遊戲執行時讀取進入。這二者的區別其實從遊戲編輯器的角度來看,分別不大。但從開發的角度上來說是有些差異的,首先當然是這些資料是如何產生的。

以一個常見的角色扮演遊戲來說,遊戲中的角色資料,可能是在MS Excel或是Google Spreadsheet中完成,故以CSV檔案滙出後進行引用。又若是利用了某個第三方網路工具進行製作,但目前主流的網路滙出格式不是json、yml要不然就是xml。這些都是文字形態的資料。而在Photoshop裡畫的角色圖片,不論是以psd檔或是png、jpg檔滙出,而後引用,這些則為二進位的內容檔。

在Unity編輯器中,可同時兼容這些檔案,然在實際的開發中,文字檔案的内容若是可以調整成二進位格式的內容,在遊戲執行時讀取的效率會有著良好的表現。而Unity很前期的版本就有其通用的二進位資料格式-ScriptableObject(SO)。早些年的開發者比較少用SO,多以Prefab的鑲嵌資料,然隨著Unity官方和開發者陸續的宣傳㰻吹,

近年來,不少開發團隊都已經適應了SO在專案中的使用。因此,在開發中或多或少會有個環節會將外來的文字檔案,如csv、json、xml等進行轉換成SO後再於遊戲中引用。

這些被SO化的文字檔連同原先已是二進位內容的圖像檔、聲音檔,於現今的開發中還有更進一步的處理,那就是以Asset Bundle(AB)的形態於遊戲中進行加載。

AB的概念本身不複雜,若是遊戲資料過大,又或是遊戲內容變動性高、擴充性高。都可以利用Unity提供的AB進行動態引用。舉個例子,若是在開發手機遊戲時,若是美術資料檔案過大,可利用將多數資料放入到AB中,待遊戲開始時再進行動態的加載,這即是AB的使用案例中常見的。由於這次並不是要探討AB,其原理和製作就不特別提及。但可適用的案例或相關資訊可從以下的資料略窺一二

而從上述的二個製程中,在以往,多數是由程式設計師專門負責、處理。然Unity日本開發團隊看到了Unity編輯器當中非程式人員也可協助進行處理檔案轉換和放入AB的項目,故於數年前展開了AssetGraph(AG)工具的製作,而在多年的調整、功能增加後,現已置入Unity主要的GitHub中,以開源方式釋出,讓開發者可以自由使用。

數年前剛接觸到AssetGraph時就認為它會加惠於廣大的開發者,但當時其功能陽春,日本團隊在文件的維護上讓人不易切入,故當下沒有花太多心思研究,也沒有放入到開發的製程中。因緣際會下,和同事閒談中再度喚起了此擴充工具。而注意到它不但回歸至Unity的主要Git Repo中,其文件也已經相當的詳細。因此在最近的工作上,有試著想要將其導入到製程中,故先行展開研究。以下的文章會是了解AG不錯的進入點。

基本的AssetGraph工具

看著英文版的AssetGraph User Manual進行引用,在2019.3 beta的Package裡加入這一行:

"com.unity.assetgraph": "https://github.com/Unity-Technologies/AssetGraph.git"

Unity則會依據此引用自行滙入相依的套件。

沒有細看文件的情況下,先自行嘗試了一個簡單的案例。假想的情境是要整理美術人員所給予的目錄,後續必要的圖檔集中擺放於另一目錄後再於專案中進行使用。此情境中,圖檔擺放在_/Art Assets/下,並於子目錄中放入了說明文檔。利用現成所提供的功能節點(Graph Node)進行處理,將其圖檔(不含文件檔)放入到_/Exported目錄下。

產生了一個AssetGraph專有的檔案-AssetGraph - First Attempt。

First Attempt

利用了這些節點

  • Load From Directory
  • Group By File Path
  • Split By Filter
  • Export To Directory

於預設的使用情境下可完成大致的需求,但仍有些不如預期的狀況,首先是擺放到另一個目錄下時不能保有部份子目錄,在此情況下,不是從Assets目錄開始整個進來,要不然是於Export To Directory時勾選了Flatten Directory後,僅檔案本身被複製。而另一個不理想的情況是圖檔仍是以Texture方式複製,而不是更加精準的Sprite型別,而於Split By Filter的型別過濾選單中無法選取到Sprite。用Sprite Altas並無預期的結果。

但使用Split By Filter後,至少可將圖檔以外的檔案隔離,且節點可以自行命名這點也有助於日後的維護。

牛刀小試產生AG後,第一時間的感想是,整個視覺化工具的框架已相對完善,有不錯的潛能,但相較於其它的視覺化工具所提供的節點,AG提供的數量並不多。而且在預設的使用情境下,其實也不是很理想。感覺起來是必需進行客製化的節點撰寫,才能更加的符合使用需求。

今日測試用的專案放罝在Git Repo中的simple-asset-graph目錄裡,有興趣的開發者可以自行下載了解。


上一篇
踏上鐵人的初賽
下一篇
撰寫客製化的AssetGraph節點
系列文
探索Unity中的視覺化製作工具30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言